Обсуждение

Например, большинство заинтересованных лиц предпочитают иметь приложение, которое не полностью соответствует тому, что они хотят, но при этом минимизировать стоимость и время разработки приложения. Кроме того, эти приоритеты часто противоречат друг другу. Другой пример состоит в том, что если  мы разрабатываем поставляемое приложение,  мы можем доставить его быстрее и дешевле, но мы должны достигнуть многих компромиссов в выполнении требований. Если вместо этого мы выберем разработку приложения с нуля, то мы сможем выполнить все желаемые требования, но стоимость и сроки выполнения проекта могут выйти за допустимые пределы.

Использование компонентов может значительно уменьшить стоимость и сроки выполнения определенного набора функций. Во многих случаях мы должны также найти компромисс между функциональными и техническими требованиями, такими как поддержка платформы, быстродействие или физический размер приложения.

Для достижения баланса потребностей мы должны прежде всего эффективно управлять требованиями, как это описано в  Справочные Материалы: Управление требованиями. Нужно не направлять усилия коллектива разработчиков на выполнение каждого пункта в списке требований, а понять и распределить приоритеты потребностей бизнеса и заинтересованного лица. Это означает выделение бизнес-процессов и соединение их в проекты и группы функций программного обеспечения, что позволяет эффективно распределять приоритеты проектов и требований, а также изменять их по мере понимания нами сути приложения и потребностей заинтересованного лица. Это также означает, что нам нужно привлекать заказчика или его представителя к участию в проекте, чтобы обеспечить понимание их потребностей.

В то же время, нужно сосредоточить процесс разработки вокруг потребностей заинтересованного лица. Например, с помощью разработки на основе прецедентов и дизайна, ориентированного на пользователя, наш процесс разработки сможет учесть изменение  потребностей заинтересованного лица в ходе выполнения проекта как  функцию изменения  бизнеса и нашего понимания  функций , которые действительно важны для бизнеса и конечных пользователей.  

Наконец, нам нужно понять, какие ресурсы мы можем использовать и  найти баланс между их повторным использованием и потребностями заинтересованного лица. Примерами использования ресурсов являются наследование приложений, служб, компонентов и шаблонов. Во многих случаях, повторное использование ресурсов может уменьшить стоимость проекта. Повторное использование испытанных ресурсов часто означает более высокое качество новых приложений. Недостатком этого во многих случаях является  необходимость поиска компромиссов между точным удовлетворением потребностей пользователя и повторным использованием ресурсов. Повторное использование компонента может уменьшить стоимость разработки комплекта на 80 процентов, но при этом удовлетворить только 75 процентов потребностей. Таким образом, эффективное повторное использование требует постоянного баланса с потребностями заинтересованного лица.